home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1172 < prev    next >
Text File  |  1995-07-25  |  74KB  |  2,313 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         D. Perkins
  8. Request for Comments: 1172                                           CMU
  9.                                                                 R. Hobby
  10.                                                                 UC Davis
  11.                                                                July 1990
  12.  
  13.  
  14.  
  15.     The Point-to-Point Protocol (PPP) Initial Configuration Options
  16.  
  17.  
  18.  
  19. Status of this Memo
  20.  
  21.    This RFC specifies an IAB standards track protocol for the Internet
  22.    community.
  23.  
  24.    Please refer to the current edition of the "IAB Official Protocol
  25.    Standards" for the standardization state and status of this protocol.
  26.  
  27.    This proposal is the product of the Point-to-Point Protocol Working
  28.    Group of the Internet Engineering Task Force (IETF).  Comments on
  29.    this memo should be submitted to the IETF Point-to-Point Protocol
  30.    Working Group chair.
  31.  
  32.    Distribution of this memo is unlimited.
  33.  
  34. Abstract
  35.  
  36.    The Point-to-Point Protocol (PPP) provides a method for transmitting
  37.    datagrams over serial point-to-point links.  PPP is composed of
  38.  
  39.       1) a method for encapsulating datagrams over serial links,
  40.       2) an extensible Link Control Protocol (LCP), and
  41.       3) a family of Network Control Protocols (NCP) for establishing
  42.       and configuring different network-layer protocols.
  43.  
  44.    The PPP encapsulating scheme, the basic LCP, and an NCP for
  45.    controlling and establishing the Internet Protocol (IP) (called the
  46.    IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol
  47.    (PPP) [1].
  48.  
  49.    This document defines the intial options used by the LCP and IPCP. It
  50.    also defines a method of Link Quality Monitoring and a simple
  51.    authentication scheme.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Perkins & Hobby                                                 [Page i]
  59.  
  60. RFC 1172                  PPP Initial Options                  July 1990
  61.  
  62.  
  63.                            Table of Contents
  64.  
  65.  
  66.      1.     Introduction ..........................................    1
  67.  
  68.      2.     Link Control Protocol (LCP) Configuration Options .....    1
  69.         2.1       Maximum-Receive-Unit ............................    2
  70.         2.2       Async-Control-Character-Map .....................    3
  71.         2.3       Authentication-Type .............................    5
  72.         2.4       Magic-Number ....................................    7
  73.         2.5       Link-Quality-Monitoring .........................   10
  74.         2.6       Protocol-Field-Compression ......................   11
  75.         2.7       Address-and-Control-Field-Compression ...........   13
  76.  
  77.      3.     Link Quality Monitoring ...............................   15
  78.         3.1       Design Motivation ...............................   15
  79.         3.2       Design Overview .................................   15
  80.         3.3       Processes .......................................   16
  81.         3.4       Counters ........................................   18
  82.         3.5       Measurements, Calculations, State Variables .....   19
  83.         3.6       Link-Quality-Report Packet Format ...............   21
  84.         3.7       Policy Suggestions ..............................   25
  85.         3.8       Example .........................................   25
  86.  
  87.      4.     Password Authentication Protocol ......................   27
  88.         4.1       Packet Format ...................................   27
  89.         4.2       Authenticate ....................................   29
  90.         4.3       Authenticate-Ack ................................   31
  91.         4.4       Authenticate-Nak ................................   32
  92.  
  93.      5.     IP Control Protocol (IPCP) Configuration Options ......   33
  94.         5.1       IP-Addresses ....................................   34
  95.         5.2       Compression-Type ................................   36
  96.  
  97.      REFERENCES ...................................................   37
  98.  
  99.      SECURITY CONSIDERATIONS ......................................   37
  100.  
  101.      AUTHOR'S ADDRESS .............................................   37
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Perkins & Hobby                                                [Page ii]
  115.  
  116. RFC 1172                  PPP Initial Options                  July 1990
  117.  
  118.  
  119. 1.  Introduction
  120.  
  121.    The Point-to-Point Protocol (PPP) [1] proposes a standard method of
  122.    encapsulating IP datagrams, and other Network Layer protocol
  123.    information, over point-to-point links.  PPP also proposes an
  124.    extensible Option Negotiation Protocol.  [1] specifies only the
  125.    protocol itself; the initial set of Configuration Options are
  126.    described in this document.  These Configuration Options allow MTUs
  127.    to be changed, IP addresses to be dynamically assigned, header
  128.    compression to be enabled, and much more.
  129.  
  130.    This memo is divided into several sections.  Section 2 describes
  131.    Configuration Options for the Link Control Protocol. Section 3
  132.    specifies the use of the Link Quality Monitoring option. Section 4
  133.    defines a simple Password Authentication Protocol. Finally, Section 5
  134.    specifies Configuration Options for the IP Control Protocol.
  135.  
  136. 2.  Link Control Protocol (LCP) Configuration Options
  137.  
  138.    As described in [1], LCP Configuration Options allow modifications to
  139.    the standard characteristics of a point-to-point link to be
  140.    negotiated.  Negotiable modifications proposed in this document
  141.    include such things as the maximum receive unit, async control
  142.    character mapping, the link authentication method, etc.
  143.  
  144.    The initial proposed values for the LCP Configuration Option Type
  145.    field (see [1]) are assigned as follows:
  146.  
  147.       1       Maximum-Receive-Unit
  148.       2       Async-Control-Character-Map
  149.       3       Authentication-Type
  150.       4       NOT ASSIGNED
  151.       5       Magic-Number
  152.       6       Link-Quality-Monitoring
  153.       7       Protocol-Field-Compression
  154.       8       Address-and-Control-Field-Compression
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Perkins & Hobby                                                 [Page 1]
  171.  
  172. RFC 1172                  PPP Initial Options                  July 1990
  173.  
  174.  
  175. 2.1.  Maximum-Receive-Unit
  176.  
  177.    Description
  178.  
  179.       This Configuration Option provides a way to negotiate the maximum
  180.       packet size used across one direction of a link.  By default, all
  181.       implementations must be able to receive frames with 1500 octets of
  182.       Information.
  183.  
  184.       This Configuration Option may be sent to inform the remote end
  185.       that you can receive larger frames, or to request that the remote
  186.       end send you smaller frames.  If smaller frames are requested, an
  187.       implementation MUST still be able to receive 1500 octet frames in
  188.       case link synchronization is lost.
  189.  
  190.    A summary of the Maximum-Receive-Unit Configuration Option format is
  191.    shown below.  The fields are transmitted from left to right.
  192.  
  193.     0                   1                   2                   3
  194.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  195.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  196.    |     Type      |    Length     |      Maximum-Receive-Unit     |
  197.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  198.  
  199.    Type
  200.  
  201.       1
  202.  
  203.    Length
  204.  
  205.       4
  206.  
  207.    Maximum-Receive-Unit
  208.  
  209.       The Maximum-Receive-Unit field is two octets and indicates the new
  210.       maximum receive unit.  The Maximum-Receive-Unit covers only the
  211.       Data Link Layer Information field but not the header, trailer or
  212.       any transparency bits or bytes.
  213.  
  214.    Default
  215.  
  216.       1500
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Perkins & Hobby                                                 [Page 2]
  227.  
  228. RFC 1172                  PPP Initial Options                  July 1990
  229.  
  230.  
  231. 2.2.  Async-Control-Character-Map
  232.  
  233.    Description
  234.  
  235.       This Configuration Option provides a way to negotiate the use of
  236.       control character mapping on asynchronous links.  By default, PPP
  237.       maps all control characters into an appropriate two character
  238.       sequence.  However, it is rarely necessary to map all control
  239.       characters and often times it is unnecessary to map any
  240.       characters.  A PPP implementation may use this Configuration
  241.       Option to inform the remote end which control characters must
  242.       remain mapped and which control characters need not remain mapped
  243.       when the remote end sends them.  The remote end may still send
  244.       these control characters in mapped format if it is necessary
  245.       because of constraints at its (the remote) end.  This option does
  246.       not solve problems for communications links that can send only 7-
  247.       bit characters or that can not send all non-control characters.
  248.  
  249.       There may be some use of synchronous-to-asynchronous converters
  250.       (some built into modems) in Point-to-point links resulting in a
  251.       synchronous PPP implementation on one end of a link and an
  252.       asynchronous implemention on the other. It is the responsibility
  253.       of the converter to do all mapping conversions during operation.
  254.       To enable this functionality, synchronous PPP implementations MUST
  255.       always accept a Async-Control-Character-Map Configuration Option
  256.       (it MUST always respond to an LCP Configure-Request specifying
  257.       this Configuration Option with an LCP Configure-Ack). However,
  258.       acceptance of this Configuration Option does not imply that the
  259.       synchronous implementation will do any character mapping, since
  260.       synchronous PPP uses bit-stuffing rather than character-stuffing.
  261.       Instead, all such character mapping will be performed by the
  262.       asynchronous-to-synchronous converter.
  263.  
  264.    A summary of the Async-Control-Character-Map Configuration Option
  265.    format is shown below.  The fields are transmitted from left to
  266.    right.
  267.  
  268.     0                   1                   2                   3
  269.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  270.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  271.    |     Type      |    Length     |  Async-Control-Character-Map
  272.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  273.              (cont)                |
  274.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  275.  
  276.    Type
  277.  
  278.       2
  279.  
  280.  
  281.  
  282. Perkins & Hobby                                                 [Page 3]
  283.  
  284. RFC 1172                  PPP Initial Options                  July 1990
  285.  
  286.  
  287.    Length
  288.  
  289.       6
  290.  
  291.    Async-Control-Character-Map
  292.  
  293.       The Async-Control-Character-Map field is four octets and indicates
  294.       the new async control character map.  The map is encoded in big-
  295.       endian fashion where each numbered bit corresponds to the ASCII
  296.       control character of the same value.  If the bit is cleared to
  297.       zero, then that ASCII control character need not be mapped.  If
  298.       the bit is set to one, then that ASCII control character must
  299.       remain mapped.  E.g., if bit 19 is set to zero, then the ASCII
  300.       control character 19 (DC3, Control-S) may be sent in the clear.
  301.  
  302.    Default
  303.  
  304.       All ones (0xffffffff).
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Perkins & Hobby                                                 [Page 4]
  339.  
  340. RFC 1172                  PPP Initial Options                  July 1990
  341.  
  342.  
  343. 2.3.  Authentication-Type
  344.  
  345.    Description
  346.  
  347.       On some links it may be desirable to require a peer to
  348.       authenticate itself before allowing Network Layer protocol data to
  349.       be exchanged.  This Configuration Option provides a way to
  350.       negotiate the use of a specific authentication protocol.  By
  351.       default, authentication is not necessary.  If an implementation
  352.       requires that the remote end authenticate with some specific
  353.       authentication protocol, then it should negotiate the use of that
  354.       authentication protocol with this Configuration Option.
  355.  
  356.       Successful negotiation of the Authentication-Type option adds an
  357.       additional Authentication phase to the Link Control Protocol.
  358.       This phase is after the Link Quality Determination phase, and
  359.       before the Network Layer Protocol Configuration Negotiation phase.
  360.       Advancement from the Authentication phase to the Network Layer
  361.       Protocol Configuration Negotiation phase may not occur until the
  362.       peer is successfully authenticated using the negotiated
  363.       authentication protocol.
  364.  
  365.       An implementation may allow the remote end to pick from more than
  366.       one authentication protocol. To achieve this, it may include
  367.       multiple Authentication-Type Configuration Options in its
  368.       Configure-Request packets.  An implementation receiving a
  369.       Configure-Request specifying multiple Authentication-Types may
  370.       accept at most one of the negotiable authentication protocols and
  371.       should send a Configure-Reject specifying all of the other
  372.       specified authentication protocols.
  373.  
  374.       It is recommended that each PPP implementation support
  375.       configuration of authentication parameters at least on a per-
  376.       interface basis, if not a per peer entity basis.  The parameters
  377.       should specify which authetication techniques are minimally
  378.       required as a prerequisite to establishment of a PPP connection,
  379.       either for the specified interface or for the specified peer
  380.       entity.  Such configuration facilities are necessary to prevent an
  381.       attacker from negotiating a reduced security authentication
  382.       protocol, or no authentication at all, in an attempt to circumvent
  383.       this authentication facility.
  384.  
  385.       If an implementation sends a Configure-Ack with this Configuration
  386.       Option, then it is agreeing to authenticate with the specified
  387.       protocol.  An implementation receiving a Configure-Ack with this
  388.       Configuration Option should expect the remote end to authenticate
  389.       with the acknowledged protocol.
  390.  
  391.  
  392.  
  393.  
  394. Perkins & Hobby                                                 [Page 5]
  395.  
  396. RFC 1172                  PPP Initial Options                  July 1990
  397.  
  398.  
  399.       There is no requirement that authentication be full duplex or that
  400.       the same authentication protocol be used in both directions.  It
  401.       is perfectly acceptable for different authentication protocols to
  402.       be used in each direction.  This will, of course, depend on the
  403.       specific authentication protocols negotiated.
  404.  
  405.       This document defines a simple Password Authentication Protocol in
  406.       Section 4.  Development of other more secure protocols is
  407.       encouraged.
  408.  
  409.    A summary of the Authentication-Type Configuration Option format is
  410.    shown below.  The fields are transmitted from left to right.
  411.  
  412.     0                   1                   2                   3
  413.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  414.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  415.    |     Type      |    Length     |     Authentication-Type       |
  416.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  417.    |    Data ...
  418.    +-+-+-+-+
  419.  
  420.    Type
  421.  
  422.       3
  423.  
  424.    Length
  425.  
  426.       >= 4
  427.  
  428.    Authentication-Type
  429.  
  430.       The Authentication-Type field is two octets and indicates the type
  431.       of authentication protocol desired.  Values for the
  432.       Authentication-Type are always the same as the PPP Data Link Layer
  433.       Protocol field values for that same authentication protocol.  The
  434.       most up-to-date values of the Authentication-Type field are
  435.       specified in "Assigned Numbers" [2].  Initial values are assigned
  436.       as follows:
  437.  
  438.          Value (in hex)          Protocol
  439.  
  440.          c023                    Password Authentication Protocol
  441.  
  442.    Data
  443.  
  444.       The Data field is zero or more octets and contains additional data
  445.       as determined by the particular authentication protocol.
  446.  
  447.  
  448.  
  449.  
  450. Perkins & Hobby                                                 [Page 6]
  451.  
  452. RFC 1172                  PPP Initial Options                  July 1990
  453.  
  454.  
  455.    Default
  456.  
  457.       No authentication protocol necessary.
  458.  
  459.  
  460. 2.4.  Magic-Number
  461.  
  462.    Description
  463.  
  464.       This Configuration Option provides a way to detect looped-back
  465.       links and other Data Link Layer anomalies.  This Configuration
  466.       Option may be required by some other Configuration Options such as
  467.       the Link-Quality-Monitoring Configuration Option.
  468.  
  469.       Before this Configuration Option is requested, an implementation
  470.       must choose its Magic-Number.  It is recommended that the Magic-
  471.       Number be chosen in the most random manner possible in order to
  472.       guarantee with very high probability that an implementation will
  473.       arrive at a unique number.  A good way to choose a unique random
  474.       number is to start with an unique seed. Suggested sources of
  475.       uniqueness include machine serial numbers, other network hardware
  476.       addresses, time-of-day clocks, etc.  Particularly good random
  477.       number seeds are precise measurements of the inter-arrival time of
  478.       physical events such as packet reception on other connected
  479.       networks, server response time, or the typing rate of a human
  480.       user.  It is also suggested that as many sources as possible be
  481.       used simultaneously.
  482.  
  483.       When a Configure-Request is received with a Magic-Number
  484.       Configuration Option, the received Magic-Number should be compared
  485.       with the Magic-Number of the last Configure-Request sent to the
  486.       peer.  If the two Magic-Numbers are different, then the link is
  487.       not looped-back, and the Magic-Number should be acknowledged.  If
  488.       the two Magic-Numbers are equal, then it is possible, but not
  489.       certain, that the link is looped-back and that this Configure-
  490.       Request is actually the one last sent.  To determine this, a
  491.       Configure-Nak should be sent specifying a different Magic-Number
  492.       value.  A new Configure-Request should not be sent to the peer
  493.       until normal processing would cause it to be sent (i.e., until a
  494.       Configure-Nak is received or the Restart timer runs out).
  495.  
  496.       Reception of a Configure-Nak with a Magic-Number different from
  497.       that of the last Configure-Nak sent to the peer proves that a link
  498.       is not looped-back, and indicates a unique Magic-Number.  If the
  499.       Magic-Number is equal to the one sent in the last Configure-Nak,
  500.       the possibility of a loop-back is increased, and a new Magic-
  501.       Number should be chosen.  In either case, a new Configure-Request
  502.       should be sent with the new Magic-Number.
  503.  
  504.  
  505.  
  506. Perkins & Hobby                                                 [Page 7]
  507.  
  508. RFC 1172                  PPP Initial Options                  July 1990
  509.  
  510.  
  511.       If the link is indeed looped-back, this sequence (transmit
  512.       Configure-Request, receive Configure-Request, transmit Configure-
  513.       Nak, receive Configure-Nak) will repeat over and over again.  If
  514.       the link is not looped-back, this sequence may occur a few times,
  515.       but it is extremely unlikely to occur repeatedly.  More likely,
  516.       the Magic-Numbers chosen at either end will quickly diverge,
  517.       terminating the sequence.  The following table shows the
  518.       probability of collisions assuming that both ends of the link
  519.       select Magic-Numbers with a perfectly uniform distribution:
  520.  
  521.          Number of Collisions        Probability
  522.          --------------------   ---------------------
  523.                  1              1/2**32    = 2.3 E-10
  524.                  2              1/2**32**2 = 5.4 E-20
  525.                  3              1/2**32**3 = 1.3 E-29
  526.  
  527.       Good sources of uniqueness or randomness are required for this
  528.       divergence to occur.  If a good source of uniqueness cannot be
  529.       found, it is recommended that this Configuration Option not be
  530.       enabled; Configure-Requests with the option should not be
  531.       transmitted and any Magic-Number Configuration Options which the
  532.       peer sends should be either acknowledged or rejected.  In this
  533.       case, loop-backs cannot be reliably detected by the
  534.       implementation, although they may still be detectable by the peer.
  535.  
  536.       If an implementation does transmit a Configure-Request with a
  537.       Magic-Number Configuration Option, then it MUST NOT respond with a
  538.       Configure-Reject if its peer also transmits a Configure-Request
  539.       with a Magic-Number Configuration Option.  That is, if an
  540.       implementation desires to use Magic Numbers, then it MUST also
  541.       allow its peer to do so.  If an implementation does receive a
  542.       Configure-Reject in response to a Configure-Request, it can only
  543.       mean that the link is not looped-back, and that its peer will not
  544.       be using Magic-Numbers.  In this case, an implementation may act
  545.       as if the negotiation had been successful (as if it had instead
  546.       received a Configure-Ack).
  547.  
  548.       The Magic-Number also may be used to detect looped-back links
  549.       during normal operation as well as during Configuration Option
  550.       negotiation.  All Echo-Request, Echo-Reply, Discard-Request, and
  551.       Link-Quality-Report LCP packets have a Magic-Number field which
  552.       MUST normally be transmitted as zero, and MUST normally be ignored
  553.       on reception.  However, once a Magic-Number has been successfully
  554.       negotiated, an LCP implementation MUST begin transmitting these
  555.       packets with the Magic-Number field set to its negotiated Magic-
  556.       Number.  Additionally, the Magic-Number field of these packets may
  557.       be inspected on reception. All received Magic-Number fields should
  558.       be equal to either zero or the peer's unique Magic-Number,
  559.  
  560.  
  561.  
  562. Perkins & Hobby                                                 [Page 8]
  563.  
  564. RFC 1172                  PPP Initial Options                  July 1990
  565.  
  566.  
  567.       depending on whether or not the peer negotiated one.  Reception of
  568.       a Magic-Number field equal to the negotiated local Magic-Number
  569.       indicates a looped-back link.  Reception of a Magic-Number other
  570.       than the negotiated local Magic-Number or or the peer's negotiated
  571.       Magic-Number, or zero if the peer didn't negotiate one, indicates
  572.       a link which has been (mis)configured for communications with a
  573.       different peer.
  574.  
  575.       Procedures for recovery from either case are unspecified and may
  576.       vary from implementation to implementation.  A somewhat
  577.       pessimistic procedure is to assume an LCP Physical-Layer-Down
  578.       event and make an immediate transition to the Closed state.  A
  579.       further Active-Open event will begin the process of re-
  580.       establishing the link, which can't complete until the loop-back
  581.       condition is terminated and Magic-Numbers are successfully
  582.       negotiated.  A more optimistic procedure (in the case of a loop-
  583.       back) is to begin transmitting LCP Echo-Request packets until an
  584.       appropriate Echo-Reply is received, indicating a termination of
  585.       the loop-back condition.
  586.  
  587.    A summary of the Magic-Number Configuration Option format is shown
  588.    below.  The fields are transmitted from left to right.
  589.  
  590.     0                   1                   2                   3
  591.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  592.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  593.    |     Type      |    Length     |          Magic-Number
  594.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  595.        Magic-Number (cont)         |
  596.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  597.  
  598.    Type
  599.  
  600.       5
  601.  
  602.    Length
  603.  
  604.       6
  605.  
  606.    Magic-Number
  607.  
  608.       The Magic-Number field is four octets and indicates a number which
  609.       is very likely to be unique to one end of the link.  A Magic-
  610.       Number of zero is illegal and must not be sent.
  611.  
  612.    Default
  613.  
  614.       None.
  615.  
  616.  
  617.  
  618. Perkins & Hobby                                                 [Page 9]
  619.  
  620. RFC 1172                  PPP Initial Options                  July 1990
  621.  
  622.  
  623. 2.5.  Link-Quality-Monitoring
  624.  
  625.    Description
  626.  
  627.       On some links it may be desirable to determine when, and how
  628.       often, the link is dropping data.  This process is called Link
  629.       Quality Monitoring and is implemented by periodically transmitting
  630.       Link-Quality-Report packets as described in Section 3.  The Link-
  631.       Quality-Monitoring Configuration Option provides a way to enable
  632.       the use of Link-Quality-Report packets, and also to negotiate the
  633.       rate at which they are transmitted.  By default, Link Quality
  634.       Monitoring and the use of Link-Quality-Report packets is disabled.
  635.  
  636.    A summary of the Link-Quality-Monitoring Configuration Option format
  637.    is shown below.  The fields are transmitted from left to right.
  638.  
  639.     0                   1                   2                   3
  640.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  641.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  642.    |     Type      |    Length     |        Reporting-Period
  643.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  644.        Reporting-Period (cont)     |
  645.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  646.  
  647.    Type
  648.  
  649.       6
  650.  
  651.    Length
  652.  
  653.       6
  654.  
  655.    Reporting-Period
  656.  
  657.       The Reporting-Period field is four octets and indicates the
  658.       maximum time in micro-seconds that the remote end should wait
  659.       between transmission of LCP Link-Quality-Report packets.  A value
  660.       of zero is illegal and should always be nak'd or rejected.  An LCP
  661.       implementation is always free to transmit LCP Link-Quality-Report
  662.       packets at a faster rate than that which was requested by, and
  663.       acknowledged to, the remote end.
  664.  
  665.    Default
  666.  
  667.       None
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Perkins & Hobby                                                [Page 10]
  675.  
  676. RFC 1172                  PPP Initial Options                  July 1990
  677.  
  678.  
  679. 2.6.  Protocol-Field-Compression
  680.  
  681.    Description
  682.  
  683.       This Configuration Option provides a way to negotiate the
  684.       compression of the Data Link Layer Protocol field.  By default,
  685.       all implementations must transmit standard PPP frames with two
  686.       octet Protocol fields. However, PPP Protocol field numbers are
  687.       chosen such that some values may be compressed into a single octet
  688.       form which is clearly distinguishable from the two octet form.
  689.       This Configuration Option may be sent to inform the remote end
  690.       that you can receive compressed single octet Protocol fields.
  691.       Compressed Protocol fields may not be transmitted unless this
  692.       Configuration Option has been received.
  693.  
  694.       As previously mentioned, the Protocol field uses an extension
  695.       mechanism consistent with the ISO 3309 extension mechanism for the
  696.       Address field; the Least Significant Bit (LSB) of each octet is
  697.       used to indicate extension of the Protocol field.  A binary "0" as
  698.       the LSB indicates that the Protocol field continues with the
  699.       following octet.  The presence of a binary "1" as the LSB marks
  700.       the last octet of the Protocol field.  Notice that any number of
  701.       "0" octets may be prepended to the field, and will still indicate
  702.       the same value (consider the two representations for 3, 00000011
  703.       and 00000000 00000011).
  704.  
  705.       In the interest of simplicity, the standard PPP frame uses this
  706.       fact and always sends Protocol fields with a two octet
  707.       representation.  Protocol field values less than 256 (decimal) are
  708.       prepended with a single zero octet even though transmission of
  709.       this, the zero and most significant octet, is unnecessary.
  710.  
  711.       However, when using low speed links, it is desirable to conserve
  712.       bandwidth by sending as little redundant data as possible.  The
  713.       Protocol Compression Configuration Option allows a trade-off
  714.       between implementation simplicity and bandwidth efficiency.  If
  715.       successfully negotiated, the ISO 3309 extension mechanism may be
  716.       used to compress the Protocol field to one octet instead of two.
  717.       The large majority of frames are compressible since data protocols
  718.       are typically assigned with Protocol field values less than 256.
  719.  
  720.       To guarantee unambiguous recognition of LCP packets, the Protocol
  721.       field must never be compressed when sending any LCP packet.  In
  722.       addition, PPP implementations must continue to be robust and MUST
  723.       accept PPP frames with double-octet, as well as single-octet,
  724.       Protocol fields, and MUST NOT distinguish between them.
  725.  
  726.       When a Protocol field is compressed, the Data Link Layer FCS field
  727.  
  728.  
  729.  
  730. Perkins & Hobby                                                [Page 11]
  731.  
  732. RFC 1172                  PPP Initial Options                  July 1990
  733.  
  734.  
  735.       is calculated on the compressed frame, not the original
  736.       uncompressed frame.
  737.  
  738.    A summary of the Protocol-Field-Compression Configuration Option
  739.    format is shown below.  The fields are transmitted from left to
  740.    right.
  741.  
  742.     0                   1
  743.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  744.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  745.    |     Type      |    Length     |
  746.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  747.  
  748.    Type
  749.  
  750.       7
  751.  
  752.    Length
  753.  
  754.       2
  755.  
  756.    Default
  757.  
  758.       Disabled.
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Perkins & Hobby                                                [Page 12]
  787.  
  788. RFC 1172                  PPP Initial Options                  July 1990
  789.  
  790.  
  791. 2.7.  Address-and-Control-Field-Compression
  792.  
  793.    Description
  794.  
  795.       This Configuration Option provides a way to negotiate the
  796.       compression of the Data Link Layer Address and Control fields.  By
  797.       default all implementations must transmit frames with Address and
  798.       Control fields and must use the hexadecimal values 0xff and 0x03
  799.       respectively.  Since these fields have constant values, they are
  800.       easily compressed.  this Configuration Option may be used to
  801.       inform the remote end that you can receive compressed Address and
  802.       Control fields.
  803.  
  804.       Compressed Address and Control fields are formed by simply
  805.       omitting them in all non-ambiguous cases.  Ambiguous frames may
  806.       not be compressed.  Ambiguous cases result when the two octets
  807.       following the Address and Control fields have values that could be
  808.       interpreted as valid Address and Control fields (i.e., 0xff,
  809.       0x03).  This can happen when Protocol-Field-Compression is enabled
  810.       and the Protocol field is compressed to one octet.  If the
  811.       Protocol value is 0xff, and the first octet of the Information
  812.       field is 0x03, the result is ambiguous and the Address and Control
  813.       fields must not be compressed on transmission.
  814.  
  815.       On reception, the Address and Control fields are decompressed by
  816.       examining the first two octets.  If they contain the values 0xff
  817.       and 0x03, they are assumed to be the Address and Control fields.
  818.       If not, it is assumed that the fields were compressed and were not
  819.       transmitted.
  820.  
  821.       One additional case in which the Address and Control fields must
  822.       never be compressed is when sending any LCP packet.  This rule
  823.       guarantees unambiguous recognition of LCP packets.
  824.  
  825.       When the Address and Control fields are compressed, the Data Link
  826.       Layer FCS field is calculated on the compressed frame, not the
  827.       original uncompressed frame.
  828.  
  829.    A summary of the Address-and-Control-Field-Compression configuration
  830.    option format is shown below.  The fields are transmitted from left
  831.    to right.
  832.  
  833.     0                   1
  834.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  835.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  836.    |     Type      |    Length     |
  837.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  838.  
  839.  
  840.  
  841.  
  842. Perkins & Hobby                                                [Page 13]
  843.  
  844. RFC 1172                  PPP Initial Options                  July 1990
  845.  
  846.  
  847.    Type
  848.  
  849.       8
  850.  
  851.    Length
  852.  
  853.       2
  854.  
  855.    Default
  856.  
  857.       Not compressed.
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Perkins & Hobby                                                [Page 14]
  899.  
  900. RFC 1172                  PPP Initial Options                  July 1990
  901.  
  902.  
  903. 3.  Link Quality Monitoring
  904.  
  905.    Data communications links are rarely perfect. Packets can be dropped
  906.    or corrupted for various reasons (line noise, equipment failure,
  907.    buffer overruns, etc.).  Sometimes, it is desirable to determine
  908.    when, and how often, the link is dropping data.  Routers, for
  909.    example, may want to temporarily allow another route to take
  910.    precedence.  An implementation may also have the option of
  911.    disconnecting and switching to an alternate link.  The process of
  912.    determining data loss is called "Link Quality Monitoring".
  913.  
  914. 3.1.  Design Motivation
  915.  
  916.    There are many different ways to measure link quality, and even more
  917.    ways to react to it.  Rather than specifying a single scheme, Link
  918.    Quality Monitoring is divided into a "mechanism" and a "policy".  PPP
  919.    fully specifies the "mechanism" for Link Quality Monitoring by
  920.    defining the LCP Link-Quality-Report (LQR) packet and specifying a
  921.    procedure for its use.  PPP does NOT specify a Link Quality
  922.    Monitoring "policy" -- how to judge link quality or what to do when
  923.    it is inadequate.  That is left as an implementation decision, and
  924.    can be different at each end of the link.  Implementations are
  925.    allowed, and even encouraged, to experiment with various link quality
  926.    policies.  The Link Quality Monitoring mechanism specification
  927.    insures that two implementations with different policies may
  928.    communicate and interoperate.
  929.  
  930.    To allow flexible policies to be implemented, the PPP Link Quality
  931.    Monitoring mechanism measures data loss in units of packets, octets,
  932.    and Link-Quality-Reports.  Each measurement is made separately for
  933.    each half of the link, both inbound and outbound.  All measurements
  934.    are communicated to both ends of the link so that each end of the
  935.    link can implement its own link quality policy for both its outbound
  936.    and inbound links.
  937.  
  938.    Finally, the Link Quality Monitoring protocol is designed to be
  939.    implementable on many different kinds of systems. Although it may be
  940.    common to implement PPP (and especially Link Quality Monitoring) as a
  941.    single software process, multi-process implementations with hardware
  942.    support are also envisioned. The PPP Link Quality Monitoring
  943.    mechanism provides for this by careful definition of the Link-
  944.    Quality-Report packet format, and by specifiying reference points for
  945.    all data transmission and reception measurements.
  946.  
  947. 3.2.  Design Overview
  948.  
  949.    Each Link Quality Monitoring implementation maintains counts of the
  950.    number of packets and octets transmitted and successfully received,
  951.  
  952.  
  953.  
  954. Perkins & Hobby                                                [Page 15]
  955.  
  956. RFC 1172                  PPP Initial Options                  July 1990
  957.  
  958.  
  959.    and periodically transmits this information to its peer in a Link-
  960.    Quality-Report packet.  These packets contain three sections: a
  961.    Header section, a Counters section, and a Measurements section.
  962.  
  963.    The Header section of the packet consists of the normal LCP Link
  964.    Maintenance packet header including Code, Identifier, Length and
  965.    Magic-Number fields.
  966.  
  967.    The Counters section of the packet consists of four counters, and
  968.    provides the information necessary to measure the quality of the
  969.    link.  The LQR transmitter fills in two of these counters: Out-Tx-
  970.    Packets-Ctr and Out-Tx-Octets-Ctr (described later).  The LQR
  971.    receiver fills in the two remaining counters: In-Rx-Packets-Ctr and
  972.    In-Rx-Octets-Ctr (described later).  These counters are similar to
  973.    sequence numbers; they are constantly increasing to give a "relative"
  974.    indication of the number of packets and octets communicated across
  975.    the outbound link.  By comparing the values in successive Link-
  976.    Quality-Reports, an LQR receiver can compute the "absolute" number of
  977.    packets and octets communicated across its inbound link. Comparing
  978.    these absolute numbers then gives an indication of an inbound link's
  979.    quality.  Relative numbers, rather than absolute, are transmitted
  980.    because they greatly simplify link synchronization; an implementation
  981.    merely waits to receive two LQR packets.
  982.  
  983.    The Measurements section of the packet consists of six state
  984.    variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In-
  985.    Rx-Packets, and In-Rx-Octets (described later).  This section allows
  986.    an implementation to report inbound link quality measurements to its
  987.    peer (for which the report will instead indicate outbound link
  988.    quality) by transmitting the absolute, rather than relative, number
  989.    of LQRs, packets, and octets communicated across the inbound link.
  990.    These values are calculated by observing the Counters section of the
  991.    Link-Quality-Report packets received on the inbound link.  Absolute
  992.    numbers may be used in this section without synchronization problems
  993.    because it is necessary to receive only one LQR packet to have valid
  994.    information.
  995.  
  996.    Link Quality Monitoring is described in more detail in the following
  997.    sections.  First, a description of the processes comprising the Link
  998.    Quality Monitoring mechanism is presented.  This is followed by the
  999.    packet and byte counters maintained; the measurements, calculations,
  1000.    and state variables used; the format of the Link-Quality-Report
  1001.    packet; some policy suggestions; and, finally, an example link
  1002.    quality calculation.
  1003.  
  1004. 3.3.  Processes
  1005.  
  1006.    The PPP Link Quality Monitoring mechanism is described using a
  1007.  
  1008.  
  1009.  
  1010. Perkins & Hobby                                                [Page 16]
  1011.  
  1012. RFC 1172                  PPP Initial Options                  July 1990
  1013.  
  1014.  
  1015.    "logical process" model. As shown below, there are five logical
  1016.    processes duplicated at each end of the duplex link.
  1017.  
  1018.    +---------+   +-------+   +----+ Outbound
  1019.    |         |-->|  Mux  |-->| Tx |=========>
  1020.    | Link-   |   +-------+   +----+
  1021.    | Manager |
  1022.    |         |   +-------+   +----+ Inbound
  1023.    |         |<--| Demux |<--| Rx |<=========
  1024.    +---------+   +-------+   +----+
  1025.  
  1026.    Link-Manager
  1027.  
  1028.       The Link-Manager process transmits and receives Link-Quality-
  1029.       Reports, and implements the desired link quality policy.  LQR
  1030.       packets are transmitted at a constant rate, which is negotiated by
  1031.       the LCP Link-Quality-Monitoring Configuration Option.  The Link-
  1032.       Manager process fills in only the Header and Measurements sections
  1033.       of the packet; the Counters section of the packet is filled in by
  1034.       the Tx and Rx processes.
  1035.  
  1036.    Mux
  1037.  
  1038.       The Mux process multiplexes packets from the various protocols
  1039.       (e.g., LCP, IP, XNS, etc.) into a single, sequential, and
  1040.       prioritized stream of packets.  Link-Quality-Report packets MUST
  1041.       be given the highest possible priority to insure that link quality
  1042.       information is communicated in a timely manner.
  1043.  
  1044.    Tx
  1045.  
  1046.       The Tx process maintains the counters Out-Tx-Packets-Ctr and Out-
  1047.       Tx-Octets-Ctr which are used to measure the amount of data which
  1048.       is transmitted on the outbound link.  When Tx processes a Link-
  1049.       Quality-Report packet, it inserts the values of these counters
  1050.       into the Counters section of the packet.  Because these counters
  1051.       represent relative, rather than absolute, values, the question of
  1052.       when to update the counters, before or after they are inserted
  1053.       into a Link-Quality-Report packet, is left as an implementation
  1054.       decision. However, an implementation MUST make this decision the
  1055.       same way every time.  The Tx process MUST follow the Mux process
  1056.       so that packets are counted in the order transmitted to the link.
  1057.  
  1058.    Rx
  1059.  
  1060.       The Rx process maintains the counters In-Rx-Packets-Ctr and In-
  1061.       Rx-Octets-Ctr which are used to measure the amount of data which
  1062.       is received by the inbound link.  When Rx processes a Link-
  1063.  
  1064.  
  1065.  
  1066. Perkins & Hobby                                                [Page 17]
  1067.  
  1068. RFC 1172                  PPP Initial Options                  July 1990
  1069.  
  1070.  
  1071.       Quality-Report packet, it inserts the values of these counters
  1072.       into the Counters section of the packet.  Again, the question of
  1073.       when to update the counters, before or after they are inserted
  1074.       into a Link-Quality-Report packet, is left as an implementation
  1075.       decision which MUST be made consistently the same way.
  1076.  
  1077.    Demux
  1078.  
  1079.       The Demux process demultiplexes packets for the various protocols.
  1080.       The Demux process MUST follow the Rx process so that packets are
  1081.       counted in the order received from the link.
  1082.  
  1083. 3.4.  Counters
  1084.  
  1085.    In order to fill in the Counters section of a Link-Quality-Report
  1086.    packet, Link Quality Monitoring requires the implementation of one
  1087.    8-bit unsigned, and four 32-bit unsigned, monotonically increasing
  1088.    counters.  These counters may be reset to any initial value before
  1089.    the first Link-Quality-Report is transmitted, but MUST NOT be reset
  1090.    again until LCP has left the Open state.  Counters wrap to zero when
  1091.    their maximum value is reached (for 32 bit counters: 0xffffffff + 1 =
  1092.    0).
  1093.  
  1094.    Out-Identifier-Ctr
  1095.  
  1096.       Out-Identifier-Ctr is an 8-bit counter maintained by the Link-
  1097.       Manager process which increases by one for each transmitted Link-
  1098.       Quality-Report packet.
  1099.  
  1100.    Out-Tx-Packets-Ctr
  1101.  
  1102.       Out-Tx-Packets-Ctr is a 32-bit counter maintained by the Tx
  1103.       process which increases by one for each transmitted Data Link
  1104.       Layer packet.
  1105.  
  1106.    Out-Tx-Octets-Ctr
  1107.  
  1108.       Out-Tx-Octets-Ctr is a 32-bit counter maintained by the Tx process
  1109.       which increases by one for each octet in a transmitted Data Link
  1110.       Layer packet.  All octets which are included in the FCS
  1111.       calculation MUST be counted, as should the FCS octets themselves.
  1112.       All other octets MUST NOT be counted.
  1113.  
  1114.    In-Rx-Packets-Ctr
  1115.  
  1116.       In-Rx-Packets-Ctr is a 32-bit counter maintained by the Rx process
  1117.       which increases by one for each successfully received Data Link
  1118.       Layer packet.  Packets with incorrect FCS fields or other problems
  1119.  
  1120.  
  1121.  
  1122. Perkins & Hobby                                                [Page 18]
  1123.  
  1124. RFC 1172                  PPP Initial Options                  July 1990
  1125.  
  1126.  
  1127.       MUST not be counted.
  1128.  
  1129.    In-Rx-Octets-Ctr
  1130.  
  1131.       In-Rx-Octets-Ctr is a 32-bit counter maintained by the Rx process
  1132.       which increases by one for each octet in a successfully received
  1133.       Data Link Layer packet.  All octets which are included in an FCS
  1134.       calculation MUST be counted, as should the FCS octets themselves.
  1135.       All other octets MUST NOT be counted.
  1136.  
  1137. 3.5.  Measurements, Calculations, State Variables
  1138.  
  1139.    In order to fill in the Measurements section of a Link-Quality-Report
  1140.    packet, Link Quality Monitoring requires the Link-Manager process to
  1141.    make a number of calculations and keep a number of state variables.
  1142.    These calculations are made, and these state variables updated, each
  1143.    time a Link-Quality-Report packet is received from the inbound link.
  1144.  
  1145.    In-Tx-LQRs
  1146.  
  1147.       In-Tx-LQRs is an 8-bit state variable which indicates the number
  1148.       of Link-Quality-Report packets which the peer had to transmit in
  1149.       order for the local end to receive exactly one LQR.  In-Tx-LQRs
  1150.       defines the length of the "period" over which In-Tx-Packets, In-
  1151.       Tx-Octets, In-Rx-Packets, and In-Rx-Octets were measured.  In-Tx-
  1152.       LQRs is calculated by subtracting Last-In-Id from the received
  1153.       Identifier.  If more than 255 LQRs in a row are lost, In-Tx-LQRs
  1154.       will be ambiguous since the Identifier field and all state
  1155.       variables based on it are only 8 bits.  It is assumed that the
  1156.       Link Quality Monitoring policy will be robust enough to handle
  1157.       this case (it should probably close down the link long before this
  1158.       happens).
  1159.  
  1160.    Last-In-Id
  1161.  
  1162.       Last-In-Id is an 8-bit state variable which stores the value of
  1163.       the last received Identifier.  Last-In-Id should be updated after
  1164.       In-Tx-LQRs has been calculated.
  1165.  
  1166.    In-Tx-Packets
  1167.  
  1168.       In-Tx-Packets is a 32-bit state variable which indicates the
  1169.       number of packets which were transmitted on the inbound link
  1170.       during the last period.  In-Tx-Packets is calculated by
  1171.       subtracting Last-Out-Tx-Packets-Ctr from the received Out-Tx-
  1172.       Packets-Ctr.
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Perkins & Hobby                                                [Page 19]
  1179.  
  1180. RFC 1172                  PPP Initial Options                  July 1990
  1181.  
  1182.  
  1183.    Last-Out-Tx-Packets-Ctr
  1184.  
  1185.       Last-Out-Tx-Packets-Ctr is a 32-bit state variable which stores
  1186.       the value of the last received Out-Tx-Packets-Ctr.  Last-Out-Tx-
  1187.       Packets-Ctr should be updated after In-Tx-Packets has been
  1188.       calculated.
  1189.  
  1190.    In-Tx-Octets
  1191.  
  1192.       In-Tx-Octets is a 32-bit state variable which indicates the number
  1193.       of octets which were transmitted on the inbound link during the
  1194.       last period.  In-Tx-Octets is calculated by subtracting Last-Out-
  1195.       Tx-Octets-Ctr from the received Out-Tx-Octets-Ctr.
  1196.  
  1197.    Last-Out-Tx-Octets-Ctr
  1198.  
  1199.       Last-Out-Tx-Octets-Ctr is a 32-bit state variable which stores the
  1200.       value of the last received Out-Tx-Octets-Ctr.  Last-Out-Tx-
  1201.       Octets-Ctr should be updated after In-Tx-Octets has been
  1202.       calculated.
  1203.  
  1204.    In-Rx-Packets
  1205.  
  1206.       In-Rx-Packets is a 32-bit state variable which indicates the
  1207.       number of packets which were received on the inbound link during
  1208.       the last period.  In-Rx-Packets is calculated by subtracting
  1209.       Last-In-Rx-Packets-Ctr from the received In-Rx-Packets-Ctr.
  1210.  
  1211.    Last-In-Rx-Packets-Ctr
  1212.  
  1213.       Last-In-Rx-Packets-Ctr is a 32-bit state variable which stores the
  1214.       value of the last received In-Rx-Packets-Ctr.  Last-In-Rx-
  1215.       Packets-Ctr should be updated after In-Rx-Packets has been
  1216.       calculated.
  1217.  
  1218.    In-Rx-Octets
  1219.  
  1220.       In-Rx-Octets is a 32-bit state variable which indicates the number
  1221.       of octets which were received on the inbound link during the last
  1222.       period.  In-Rx-Octets is calculated by subtracting Last-In-Rx-
  1223.       Octets-Ctr from the received In-Rx-Octets-Ctr.
  1224.  
  1225.    Last-In-Rx-Octets-Ctr
  1226.  
  1227.       Last-In-Rx-Octets-Ctr is a 32-bit state variable which stores the
  1228.       value of the last received In-Rx-Octets-Ctr.  Last-In-Rx-Octets-
  1229.       Ctr should be updated after In-Rx-Octets has been calculated.
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Perkins & Hobby                                                [Page 20]
  1235.  
  1236. RFC 1172                  PPP Initial Options                  July 1990
  1237.  
  1238.  
  1239.    Measurements-Valid
  1240.  
  1241.       Measurements-Valid is a 1-bit boolean state variable which
  1242.       indicates whether or not the In-Tx-Packets, In-Tx-Octets, In-Rx-
  1243.       Packets, and In-Rx-Octets state variables contain valid
  1244.       measurements.  These measurements cannot be considered valid until
  1245.       two or more Link-Quality-Report packets have been received on the
  1246.       inbound link.  This bit should be reset when LCP reaches the Open
  1247.       state and should be set after the receipt of exactly two LQRs.
  1248.  
  1249. 3.6.  Link-Quality-Report Packet Format
  1250.  
  1251.    A Summary of the Link-Quality-Report packet format is shown below.
  1252.    The fields are transmitted from left to right.  The Code, Identifier,
  1253.    Length, and Magic-Number fields make up the normal LCP Link
  1254.    Maintenance packet header; the In-Tx-LQRS, Last-In-Id, V, In-Tx-
  1255.    Packets, In-Tx-Octets, In-Rx-Packets, In-Rx-Octets fields contain
  1256.    digested absolute measurements; and the Out-Tx-Packets-Ctr, Out-Tx-
  1257.    Octets-Ctr, In-Rx-Packets-Ctr, and In-Rx-Octets-Ctr fields contain
  1258.    raw relative counts.  Note that as transmitted over the link, this
  1259.    packet format does not include the In-Rx-Packets-Ctr and In-Rx-
  1260.    Octets-Ctr fields which are logically appended to the packet by the
  1261.    Rx process after reception on the inbound link.
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Perkins & Hobby                                                [Page 21]
  1291.  
  1292. RFC 1172                  PPP Initial Options                  July 1990
  1293.  
  1294.  
  1295.     0                   1                   2                   3
  1296.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1297.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1298.    |     Code      |  Identifier   |            Length             |
  1299.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1300.    |                         Magic-Number                          |
  1301.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1302.    |  In-Tx-LQRs   |   Last-In-Id  |           Reserved          |V|
  1303.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1304.    |                         In-Tx-Packets                         |
  1305.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1306.    |                         In-Tx-Octets                          |
  1307.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1308.    |                         In-Rx-Packets                         |
  1309.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1310.    |                         In-Rx-Octets                          |
  1311.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1312.    |                       Out-Tx-Packets-Ctr                      |
  1313.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1314.    |                       Out-Tx-Octets-Ctr                       |
  1315.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1316.    /
  1317.    /
  1318.    /
  1319.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1320.    |                        In-Rx-Packets-Ctr                      |
  1321.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1322.    |                        In-Rx-Octets-Ctr                       |
  1323.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1324.  
  1325.    Code
  1326.  
  1327.       12 for Link-Quality-Report.
  1328.  
  1329.    Identifier
  1330.  
  1331.       The Identifier field is one octet and indicates the sequence
  1332.       number for this Link-Quality-Report. The Identifier field is
  1333.       copied from the Out-Identifier-Ctr counter on transmission.  On
  1334.       reception, the Identifier field is used to calculate In-Tx-LQRs
  1335.       and is then stored in Last-In-Id.
  1336.  
  1337.       The Link-Quality-Report Identifier sequence number space MUST be
  1338.       separate from that of all other LCP packets; for example,
  1339.       transmission of an LCP Echo-Request must not cause the Out-
  1340.       Identifier-Ctr counter to be incremented.
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Perkins & Hobby                                                [Page 22]
  1347.  
  1348. RFC 1172                  PPP Initial Options                  July 1990
  1349.  
  1350.  
  1351.    Length
  1352.  
  1353.       The Length field is two octets and indicates the length of the LQM
  1354.       packet including the Code, Identifier, Length and all defined
  1355.       fields. Octets outside the range of the length field should be
  1356.       treated as Data Link Layer padding and should be ignored on
  1357.       reception.  In order for the correct In-Tx-Octets and In-Rx-Octets
  1358.       values to be calculated, Link-Quality-Reports MUST be consistently
  1359.       transmitted with the same amount of padding.
  1360.  
  1361.    Magic-Number
  1362.  
  1363.       The Magic-Number field is four octets and aids in detecting
  1364.       looped-back links.  Unless modified by a Configuration Option, the
  1365.       Magic-Number MUST always be transmitted as zero and MUST always be
  1366.       ignored on reception. If Magic-Numbers have been negotiated,
  1367.       incoming LQM packets should be checked to make sure that the local
  1368.       end is not seeing its own Magic-Number and thus a looped-back
  1369.       link.
  1370.  
  1371.    In-Tx-LQRs
  1372.  
  1373.       The In-Tx-LQRs field is one octet and indicates the number of
  1374.       periods covered by the Measurements section of this Link-Quality-
  1375.       Report.  The In-Tx-LQRs field is copied from the In-Tx-LQRs state
  1376.       variable on transmission.
  1377.  
  1378.    Last-In-Id
  1379.  
  1380.       The Prev-In-Id field is one octet and indicates the age of the
  1381.       Measurements section of this Link-Quality-Report. The Last-In-Id
  1382.       field is copied from the Last-In-Id field on transmission.  On
  1383.       reception, the Last-In-Id field may be compared with the Out-
  1384.       Identifier-Ctr to determine how many, if any, outbound Link-
  1385.       Quality-Reports have been lost.
  1386.  
  1387.    V
  1388.  
  1389.       The V field is 1 bit and indicates whether or not the Measurements
  1390.       section of this Link-Quality-Report is valid.  The V field is
  1391.       copied from the Measurements-Valid state variable on transmission.
  1392.       If the V field is not set to 1, then the In-Tx-LQRs, Last-In-Id,
  1393.       In-Tx-Packets, In-Tx-Octets, In-Rx-Packets and In-Rx-Octets fields
  1394.       should be ignored.
  1395.  
  1396.    Reserved
  1397.  
  1398.       The Reserved field is 15 bits and is intended to pad the remaining
  1399.  
  1400.  
  1401.  
  1402. Perkins & Hobby                                                [Page 23]
  1403.  
  1404. RFC 1172                  PPP Initial Options                  July 1990
  1405.  
  1406.  
  1407.       packet fields to even four-octet boundaries for the convenience of
  1408.       hardware implementations. The Reserved field should always be
  1409.       transmitted as zero and ignored on reception.
  1410.  
  1411.    In-Tx-Packets
  1412.  
  1413.       The In-Tx-Packets field is four octets and indicates the number of
  1414.       packets transmitted on the inbound link of the Link-Quality-Report
  1415.       transmitter during the last measured period.  The In-Tx-Packets
  1416.       field is copied from the In-Tx-Packets state variable on
  1417.       transmission.
  1418.  
  1419.    In-Tx-Octets
  1420.  
  1421.       The In-Tx-Octets field is four octets and indicates the number of
  1422.       octets transmitted on the inbound link of the Link-Quality-Report
  1423.       transmitter during the last measured period.  The In-Tx-Octets
  1424.       field is copied from the In-Tx-Octets state variable on
  1425.       transmission.
  1426.  
  1427.    In-Rx-Packets
  1428.  
  1429.       The In-Rx-Packets field is four octets and indicates the number of
  1430.       packets received on the inbound link of the Link-Quality-Report
  1431.       transmitter during the last measured period.  The In-Rx-Packets
  1432.       field is copied from the In-Rx-Packets state variable on
  1433.       transmission.
  1434.  
  1435.    In-Rx-Octets
  1436.  
  1437.       The In-Rx-Octets field is four octets and indicates the number of
  1438.       octets received on the inbound link of the Link-Quality-Report
  1439.       transmitter during the last measured period.  The In-Rx-Octets
  1440.       field is copied from the In-Rx-Octets state variable on
  1441.       transmission.
  1442.  
  1443.    Out-Tx-Packets
  1444.  
  1445.       The Out-Tx-Packets field is four octets and is used to calculate
  1446.       the number of packets transmitted on the outbound link of the
  1447.       Link-Quality-Report transmitter during a period.  The Out-Tx-
  1448.       Packets field is copied from the Out-Tx-Packets-Ctr counter on
  1449.       transmission.
  1450.  
  1451.    Out-Tx-Octets
  1452.  
  1453.       The Out-Tx-Octets field is four octets and is used to calculate
  1454.       the number of octets transmitted on the outbound link of the
  1455.  
  1456.  
  1457.  
  1458. Perkins & Hobby                                                [Page 24]
  1459.  
  1460. RFC 1172                  PPP Initial Options                  July 1990
  1461.  
  1462.  
  1463.       Link-Quality-Report transmitter during a period.  The Out-Tx-
  1464.       Octets field is copied from the Out-Tx-Octets-Ctr counter on
  1465.       transmission.
  1466.  
  1467.    In-Rx-Packets
  1468.  
  1469.       The In-Rx-Packets field is four octets and is used to calculate
  1470.       the number of packets received on the inbound link of the Link-
  1471.       Quality-Report receiver during a period.  The In-Rx-Packets field
  1472.       is copied from the In-Rx-Packets-Ctr counter on reception.  The
  1473.       In-Rx-Packets is not shown because it is not actually transmitted
  1474.       over the link.  Rather, it is logically appended (in an
  1475.       implementation dependent manner) to the packet by the
  1476.       implementation's Rx process.
  1477.  
  1478.    In-Rx-Octets
  1479.  
  1480.       The In-Rx-Octets field is four octets and is used to calculate the
  1481.       number of octets  received on the inbound link of the Link-
  1482.       Quality-Report receiver during a period.  The In-Rx-Octets field
  1483.       is copied from the In-Rx-Octets-Ctr counter on reception.  The
  1484.       In-Rx-Octets is not shown because it is not actually transmitted
  1485.       over the link.  Rather, it is logically appended (in an
  1486.       implementation dependent manner) to the packet by the
  1487.       implementation's Rx process.
  1488.  
  1489. 3.7.  Policy Suggestions
  1490.  
  1491.    Link-Quality-Report packets provide a mechanism to determine the link
  1492.    quality, but it is up to each implementation to decide when the link
  1493.    is usable.  It is recommended that this policy implement some amount
  1494.    of hysteresis so that the link does not bounce up and down.  A
  1495.    particularly good policy is to use a K out of N algorithm.  In such
  1496.    an algorithm, there must be K successes out of the last N periods for
  1497.    the link to be considered of good quality.
  1498.  
  1499.    Procedures for recovery from poor quality links are unspecified and
  1500.    may vary from implementation to implementation.  A suggested approach
  1501.    is to immediately close all other Network-Layer protocols (i.e.,
  1502.    cause IPCP to transmit a Terminate-Req), but to continue transmitting
  1503.    Link-Quality-Reports.  Once the link quality again reaches an
  1504.    acceptable level, Network-Layer protocols can be reconfigured.
  1505.  
  1506. 3.8.  Example
  1507.  
  1508.    An example may be helpful.  Assume that Link-Manager implementation A
  1509.    transmits a Link-Quality-Report which is received by Link-Manager
  1510.    implementation B at time t0 with the following values:
  1511.  
  1512.  
  1513.  
  1514. Perkins & Hobby                                                [Page 25]
  1515.  
  1516. RFC 1172                  PPP Initial Options                  July 1990
  1517.  
  1518.  
  1519.       Out-Tx-Packets    5
  1520.       Out-Tx-Octets   100
  1521.       In-Rx-Packets     3
  1522.       In-Rx-Octets     70
  1523.  
  1524.    Assume that A then transmits 20 IP packets with 200 octets, of which
  1525.    15 packets and 150 octets are received by B.  At time t1, A transmits
  1526.    another LQR which is received by B as follows:
  1527.  
  1528.       Out-Tx-Packets   26 (5 old, plus 20 IP, plus 1 LQR)
  1529.       Out-Tx-Octets   342 (42 for LQR)
  1530.       In-Rx-Packets    19
  1531.       In-Rx-Octets    262
  1532.  
  1533.    Implementation B can now calculate the number of packets and octets
  1534.    transmitted, received and lost on its inbound link as follows:
  1535.  
  1536.       In-Tx-Packets   =  26 -   5 =  21
  1537.       In-Tx-Octets    = 342 - 100 = 242
  1538.       In-Rx-Packets   =  10 -   3 =  16
  1539.       In-Rx-Octets    = 262 -  70 = 192
  1540.       In-Lost-Packets =  21 -  16 =   5
  1541.       In-Lost-Octets  = 242 - 192 =  50
  1542.  
  1543.    After doing these calculations, B evaluates the measurements in what
  1544.    ever way its implemented policy specifies.  Also, the next time that
  1545.    B transmits an LQR to A, it will report these values in the
  1546.    Measurements section, thereby allowing A to evaluate these same
  1547.    measurements.
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Perkins & Hobby                                                [Page 26]
  1571.  
  1572. RFC 1172                  PPP Initial Options                  July 1990
  1573.  
  1574.  
  1575. 4.  Password Authentication Protocol
  1576.  
  1577.    The Password Authentication Protocol (PAP) may be used to
  1578.    authenticate a peer by verifying the identity of the remote end of
  1579.    the link.  Use of the PAP must first be negotiated using the LCP
  1580.    Authentication-Type Configuration Option.  Successful negotiation
  1581.    adds an additional Authentication phase to the Link Control Protocol,
  1582.    after the Link Quality Determination phase, and before the Network
  1583.    Layer Protocol Configuration Negotiation phase.  PAP packets received
  1584.    before the Authentication phase is reached should be silently
  1585.    discarded.  The Authentication phase is exited once an Authenticate-
  1586.    Ack packet is sent or received.
  1587.  
  1588.    PAP is intended for use primarily by hosts and routers that connect
  1589.    via switched circuits or dial-up lines to a PPP network server.  The
  1590.    server can then use the identification of the connecting host or
  1591.    router in the selection of options for network layer negotiations or
  1592.    failing authentication, drop the connection.
  1593.  
  1594.    Note that PAP is not a strong authentication method.  Passwords are
  1595.    passed over the circuit in the clear and there is no protection from
  1596.    repeated trial and error attacks.  Work is currently underway on more
  1597.    secure authentication methods for PPP and other protocols.  It is
  1598.    strongly recommended to switch to these methods when they become
  1599.    available.
  1600.  
  1601.  
  1602. 4.1.  Packet Format
  1603.  
  1604.    Exactly one Password Authentication Protocol packet is encapsulated
  1605.    in the Information field of PPP Data Link Layer frames where the
  1606.    protocol field indicates type hex c023 (Password Authentication
  1607.    Protocol).  A summary of the Password Authentication Protocol packet
  1608.    format is shown below.  The fields are transmitted from left to
  1609.    right.
  1610.  
  1611.     0                   1                   2                   3
  1612.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1613.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1614.    |     Code      |  Identifier   |            Length             |
  1615.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1616.    |    Data ...
  1617.    +-+-+-+-+
  1618.  
  1619.    Code
  1620.  
  1621.       The Code field is one octet and identifies the type of PAP packet.
  1622.       PAP Codes are assigned as follows:
  1623.  
  1624.  
  1625.  
  1626. Perkins & Hobby                                                [Page 27]
  1627.  
  1628. RFC 1172                  PPP Initial Options                  July 1990
  1629.  
  1630.  
  1631.          1       Authenticate
  1632.          2       Authenticate-Ack
  1633.          3       Authenticate-Nak
  1634.  
  1635.    Identifier
  1636.  
  1637.       The Identifier field is one octet and aids in matching requests
  1638.       and replies.
  1639.  
  1640.    Length
  1641.  
  1642.       The Length field is two octets and indicates the length of the PAP
  1643.       packet including the Code, Identifier, Length and Data fields.
  1644.       Octets outside the range of the Length field should be treated as
  1645.       Data Link Layer padding and should be ignored on reception.
  1646.  
  1647.    Data
  1648.  
  1649.       The Data field is zero or more octets.  The format of the Data
  1650.       field is determined by the Code field.
  1651.  
  1652.  
  1653.  
  1654.  
  1655.  
  1656.  
  1657.  
  1658.  
  1659.  
  1660.  
  1661.  
  1662.  
  1663.  
  1664.  
  1665.  
  1666.  
  1667.  
  1668.  
  1669.  
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Perkins & Hobby                                                [Page 28]
  1683.  
  1684. RFC 1172                  PPP Initial Options                  July 1990
  1685.  
  1686.  
  1687. 4.2.  Authenticate
  1688.  
  1689.    Description
  1690.  
  1691.       The Authenticate packet is used to begin the Password
  1692.       Authentication Protocol.  An implementation having sent a LCP
  1693.       Configure-Ack packet with an Authentication-Type Configuration
  1694.       Option further specifying the Password Authentication Protocol
  1695.       must send an Authenticate packet during the Authentication phase.
  1696.       An implementation receiving a Configure-Ack with said
  1697.       Configuration Option should expect the remote end to send an
  1698.       Authenticate packet during this phase.
  1699.  
  1700.       An Authenticate packet is sent with the Code field set to 1
  1701.       (Authenticate) and the Peer-ID and Password fields filled as
  1702.       desired.
  1703.  
  1704.       Upon reception of an Authenticate, some type of Authenticate reply
  1705.       MUST be transmitted.
  1706.  
  1707.    A summary of the Authenticate packet format is shown below.  The
  1708.    fields are transmitted from left to right.
  1709.  
  1710.     0                   1                   2                   3
  1711.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1712.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1713.    |     Code      |  Identifier   |            Length             |
  1714.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1715.    | Peer-ID Length|  Peer-Id ...
  1716.    +-+-+-+-+-+-+-+-+-+-+-+-+
  1717.    | Passwd-Length |  Password  ...
  1718.    +-+-+-+-+-+-+-+-+-+-+-+-+-+
  1719.  
  1720.    Code
  1721.  
  1722.       1 for Authenticate.
  1723.  
  1724.    Identifier
  1725.  
  1726.       The Identifier field is one octet and aids in matching requests
  1727.       and replies.  The Identifier field should be changed each time a
  1728.       Authenticate is transmitted which is different from the preceding
  1729.       request.
  1730.  
  1731.    Peer-ID-Length
  1732.  
  1733.       The Peer-ID-Length field is one octet and indicates the length of
  1734.       the Peer-ID field
  1735.  
  1736.  
  1737.  
  1738. Perkins & Hobby                                                [Page 29]
  1739.  
  1740. RFC 1172                  PPP Initial Options                  July 1990
  1741.  
  1742.  
  1743.    Peer-ID
  1744.  
  1745.       The Peer-ID field is zero or more octets and indicates the name of
  1746.       the peer to be authenticated.
  1747.  
  1748.    Passwd-Length
  1749.  
  1750.       The Passwd-Length field is one octet and indicates the length of
  1751.       the Password field
  1752.  
  1753.    Password
  1754.  
  1755.       The Password field is zero or more octets and indicates the
  1756.       password to be used for authentication.
  1757.  
  1758.  
  1759.  
  1760.  
  1761.  
  1762.  
  1763.  
  1764.  
  1765.  
  1766.  
  1767.  
  1768.  
  1769.  
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.  
  1787.  
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Perkins & Hobby                                                [Page 30]
  1795.  
  1796. RFC 1172                  PPP Initial Options                  July 1990
  1797.  
  1798.  
  1799. 4.3.  Authenticate-Ack
  1800.  
  1801.    Description
  1802.  
  1803.       If the Peer-ID/Password pair received in an Authenticate is both
  1804.       recognizable and acceptable, then a PAP implementation should
  1805.       transmit a PAP packet with the Code field set to 2 (Authenticate-
  1806.       Ack), the Identifier field copied from the received Authenticate,
  1807.       and the Message field optionally filled with an ASCII message.
  1808.  
  1809.    A summary of the Authenticate-Ack packet format is shown below.  The
  1810.    fields are transmitted from left to right.
  1811.  
  1812.     0                   1                   2                   3
  1813.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1814.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1815.    |     Code      |  Identifier   |            Length             |
  1816.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1817.    |  Msg-Length   |  Message  ...
  1818.    +-+-+-+-+-+-+-+-+-+-+-+-+-
  1819.  
  1820.    Code
  1821.  
  1822.       2 for Authenticate-Ack.
  1823.  
  1824.    Identifier
  1825.  
  1826.       The Identifier field is one octet and aids in matching requests
  1827.       and replies.  The Identifier field MUST be copied from the
  1828.       Identifier field of the Authenticate which caused this
  1829.       Authenticate-Ack.
  1830.  
  1831.    Msg-Length
  1832.  
  1833.       The Msg-Length field is one octet and indicates the length of the
  1834.       Message field
  1835.  
  1836.    Message
  1837.  
  1838.       The Message field is zero or more octets and indicates an ASCII
  1839.       message.
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Perkins & Hobby                                                [Page 31]
  1851.  
  1852. RFC 1172                  PPP Initial Options                  July 1990
  1853.  
  1854.  
  1855. 4.4.  Authenticate-Nak
  1856.  
  1857.    Description
  1858.  
  1859.       If the Peer-ID/Password pair received in a Authenticate is not
  1860.       recognizable or acceptable, then a PAP implementation should
  1861.       transmit a PAP packet with the Code field set to 3 (Authenticate-
  1862.       Nak), the Identifier field copied from the received Authenticate,
  1863.       and the Message field optionally filled with an ASCII message.
  1864.  
  1865.    A summary of the Authenticate-Nak packet format is shown below.  The
  1866.    fields are transmitted from left to right.
  1867.  
  1868.     0                   1                   2                   3
  1869.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1870.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1871.    |     Code      |  Identifier   |            Length             |
  1872.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1873.    |  Msg-Length   |  Message  ...
  1874.    +-+-+-+-+-+-+-+-+-+-+-+-+-
  1875.  
  1876.    Code
  1877.  
  1878.       3 for Authenticate-Nak.
  1879.  
  1880.    Identifier
  1881.  
  1882.       The Identifier field is one octet and aids in matching requests
  1883.       and replies.  The Identifier field MUST be copied from the
  1884.       Identifier field of the Authenticate which caused this
  1885.       Authenticate-Nak.
  1886.  
  1887.    Msg-Length
  1888.  
  1889.       The Msg-Length field is one octet and indicates the length of the
  1890.       Message field
  1891.  
  1892.    Message
  1893.  
  1894.       The Message field is zero or more octets and indicates an ASCII
  1895.       message.
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. Perkins & Hobby                                                [Page 32]
  1907.  
  1908. RFC 1172                  PPP Initial Options                  July 1990
  1909.  
  1910.  
  1911. 5.  IP Control Protocol (IPCP) Configuration Options
  1912.  
  1913. IPCP Configuration Options allow negotiatiation of desirable Internet
  1914. Protocol parameters.  Negotiable modifications proposed in this document
  1915. include IP addresses and compression protocols.
  1916.  
  1917. The initial proposed values for the IPCP Configuration Option Type field
  1918. (see [1]) are assigned as follows:
  1919.  
  1920.    1       IP-Addresses
  1921.    2       Compression-Type
  1922.  
  1923.  
  1924.  
  1925.  
  1926.  
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.  
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Perkins & Hobby                                                [Page 33]
  1963.  
  1964. RFC 1172                  PPP Initial Options                  July 1990
  1965.  
  1966.  
  1967. 5.1.  IP-Addresses
  1968.  
  1969.    Description
  1970.  
  1971.       This Configuration Option provides a way to negotiate the IP
  1972.       addresses to be used on each end of the link.  By default, no IP
  1973.       addresses are assigned to either end.  An address specified as
  1974.       zero shall be interpreted as requesting the remote end to specify
  1975.       the address.  If an implementation allows the assignment of
  1976.       multiple IP addresses, then it may include multiple IP Address
  1977.       Configuration Options in its Configure-Request packets.  An
  1978.       implementation receiving a Configure-Request specifying multiple
  1979.       IP Address Configuration Options may send a Configure-Reject
  1980.       specifying one or more of the specified IP Addresses.  An
  1981.       implementation which desires that no IP addresses be assigned
  1982.       (such as a "half-gateway") may reject all IP Address Configuration
  1983.       Options.
  1984.  
  1985.    A summary of the IP-Addresses Configuration Option format is shown
  1986.    below.  The fields are transmitted from left to right.
  1987.  
  1988.     0                   1                   2                   3
  1989.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1990.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1991.    |     Type      |    Length     |     Source-IP-Address
  1992.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1993.      Source-IP-Address (cont)      |  Destination-IP-Address
  1994.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1995.     Destination-IP-Address (cont)  |
  1996.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1997.  
  1998.    Type
  1999.  
  2000.       1
  2001.  
  2002.    Length
  2003.  
  2004.       10
  2005.  
  2006.    Source-IP-Address
  2007.  
  2008.       The four octet Source-IP-Address is the desired local address of
  2009.       the sender of a Configure-Request.  In a Configure-Ack,
  2010.       Configure-Nak or Configure-Reject, the Source-IP-Address is the
  2011.       remote address of the sender, and is thus a local address with
  2012.       respect to the Configuration Option receiver.
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Perkins & Hobby                                                [Page 34]
  2019.  
  2020. RFC 1172                  PPP Initial Options                  July 1990
  2021.  
  2022.  
  2023.    Destination-IP-Address
  2024.  
  2025.       The four octet Destination-IP-Address is the remote address with
  2026.       respect to the sender of a Configure-Request.  In a Configure-Ack,
  2027.       Configure-Nak or Configure-Reject, the Destination-IP-Address is
  2028.       the local address of the sender, and is thus a remote address with
  2029.       respect to the Configuration Option receiver.
  2030.  
  2031.    Default
  2032.  
  2033.       No IP addresses assigned.
  2034.  
  2035.  
  2036.  
  2037.  
  2038.  
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074. Perkins & Hobby                                                [Page 35]
  2075.  
  2076. RFC 1172                  PPP Initial Options                  July 1990
  2077.  
  2078.  
  2079. 5.2.  Compression-Type
  2080.  
  2081.    Description
  2082.  
  2083.       This Configuration Option provides a way to negotiate the use of a
  2084.       specific compression protocol.  By default, compression is not
  2085.       enabled.
  2086.  
  2087.    A summary of the Compression-Type Configuration Option format is
  2088.    shown below.  The fields are transmitted from left to right.
  2089.  
  2090.     0                   1                   2                   3
  2091.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2092.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2093.    |     Type      |    Length     |       Compression-Type        |
  2094.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2095.    |    Data ...
  2096.    +-+-+-+-+
  2097.  
  2098.    Type
  2099.  
  2100.       2
  2101.  
  2102.    Length
  2103.  
  2104.       >= 4
  2105.  
  2106.    Compression-Type
  2107.  
  2108.       The Compression-Type field is two octets and indicates the type of
  2109.       compression protocol desired.  Values for the Compression-Type are
  2110.       always the same as the PPP Data Link Layer Protocol field values
  2111.       for that same compression protocol.  The most up-to-date values of
  2112.       the Compression-Type field are specified in "Assigned Numbers"
  2113.       [2].  Initial values are assigned as follows:
  2114.  
  2115.          Value (in hex)          Protocol
  2116.  
  2117.          0037                    Van Jacobson Compressed TCP/IP
  2118.  
  2119.    Data
  2120.  
  2121.       The Data field is zero or more octets and contains additional data
  2122.       as determined by the compression protocol indicated in the
  2123.       Compression-Type field.
  2124.  
  2125.  
  2126.  
  2127.  
  2128.  
  2129.  
  2130. Perkins & Hobby                                                [Page 36]
  2131.  
  2132. RFC 1172                  PPP Initial Options                  July 1990
  2133.  
  2134.  
  2135.    Default
  2136.  
  2137.       No compression protocol enabled.
  2138.  
  2139.  
  2140. References
  2141.  
  2142.    [1]   Perkins, D., "The Point-to-Point Protocol for the Transmission
  2143.          of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC
  2144.          1171, July, 1990.
  2145.  
  2146.    [2]   Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
  2147.          USC/Information Sciences Institute, March 1990.
  2148.  
  2149.  
  2150. Security Considerations
  2151.  
  2152.    Security issues are discussed in Section 2.3.
  2153.  
  2154.  
  2155. Author's Address
  2156.  
  2157.    This proposal is the product of the Point-to-Point Protocol Working
  2158.    Group of the Internet Engineering Task Force (IETF). The working
  2159.    group can be contacted via the chair:
  2160.  
  2161.       Russ Hobby
  2162.       UC Davis
  2163.       Computing Services
  2164.       Davis, CA 95616
  2165.  
  2166.       Phone: (916) 752-0236
  2167.  
  2168.       EMail: rdhobby@ucdavis.edu
  2169.  
  2170.    Questions about this memo can also be directed to:
  2171.  
  2172.       Drew D. Perkins
  2173.       Carnegie Mellon University
  2174.       Networking and Communications
  2175.       Pittsburgh, PA 15213
  2176.  
  2177.       Phone: (412) 268-8576
  2178.  
  2179.       EMail: ddp@andrew.cmu.edu
  2180.  
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186. Perkins & Hobby                                                [Page 37]
  2187.  
  2188. RFC 1172                  PPP Initial Options                  July 1990
  2189.  
  2190.  
  2191. Acknowledgments
  2192.  
  2193.    Many people spent significant time helping to develop the Point-to-
  2194.    Point Protocol.  The complete list of people is too numerous to list,
  2195.    but the following people deserve special thanks: Ken Adelman (TGV),
  2196.    Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David
  2197.    Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun
  2198.    Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz
  2199.    (cisco systems) and Asher Waldfogel (Wellfleet).
  2200.  
  2201.  
  2202.  
  2203.  
  2204.  
  2205.  
  2206.  
  2207.  
  2208.  
  2209.  
  2210.  
  2211.  
  2212.  
  2213.  
  2214.  
  2215.  
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.  
  2222.  
  2223.  
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242. Perkins & Hobby                                                [Page 38]
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.  
  2249.  
  2250.  
  2251.  
  2252.  
  2253.  
  2254.  
  2255.  
  2256.  
  2257.  
  2258.  
  2259.  
  2260.  
  2261.  
  2262.  
  2263.  
  2264.  
  2265.  
  2266.  
  2267.  
  2268.  
  2269.  
  2270.  
  2271.  
  2272.  
  2273.  
  2274.  
  2275.  
  2276.  
  2277.  
  2278.  
  2279.  
  2280.  
  2281.  
  2282.  
  2283.  
  2284.  
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298.  
  2299.  
  2300.  
  2301.  
  2302.  
  2303.  
  2304.  
  2305.  
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311.  
  2312.  
  2313.